fix(dialog): auto-dismiss alerts reliably and fail fast on dialog-blocked reads - #2528

…cked reads

On Windows, alert() under the default auto-dialog handling wedged the tab:
the auto-dismiss task read dialog-opening events from the shared broadcast
receiver, which can lag and drop the opening event. A dropped event meant
the dialog was never dismissed, so the triggering command and every later
command timed out after ~30 s with os error 10060 until close reported
page_wedged. `dialog status` also reported no dialog, since auto-handled
dialogs were never tracked.

Listen for Page.javascriptDialogOpening on a lossless method tap instead of
the shared broadcast, and track every dialog in pending_dialog, including
the ones the background task auto-dismisses. The dismiss usually lands
first and the closed event clears the tracking on the next drain; but if
the dismiss is missed or fails, the dialog stays visible to `dialog
status`, the fail-fast gate, and the timeout path, so an open alert no
longer looks like a wedged tab.

Also fail fast for `url` and `title` while a dialog is open: both evaluate
JavaScript in the page, so they hung until the client read timeout instead
of reporting the blocking dialog. `dialog`, `screenshot`, and tab
management stay usable during a dialog.

Fixes vercel-labs#2511

Vercel review on vercel-labs#2528 found two issues in the dialog tracking:

1. If broadcast lag dropped an auto-dismissed alert's close event after
its opening was drained, pending_dialog stayed set forever and page
commands kept failing fast on a dialog that no longer exists. The
background task saw the same opening on its lossless tap and already
dismissed it, so on lag the tracked alert/beforeunload entry is stale:
clear it. Confirm/prompt dialogs are never auto-dismissed, so their
entries stay tracked.

2. The dialog-drain unit test always panicked: the drain's session filter
discarded dialog events with no browser attached. Dialog open/close is
daemon-global state, so dialog events bypass the session filter (the
fail-fast gate still scopes to the active tab), and a close only clears
the dialog it closed.

Vercel review on vercel-labs#2528 (comment 4523632585): tracking a background-tab
dialog without updating dialog resolution made `dialog accept` and
`dialog dismiss` target the active tab instead of the reported dialog.
BrowserManager::handle_dialog always used the active session. It now
takes the tracked dialog's session (falling back to the active session
when none is recorded, e.g. a top-level page dialog), and the CLI
`dialog` handler passes pending_dialog's session_id. The fail-fast gate
already scoped blocking to the active tab; only the resolution path was
still active-tab bound.

New mock-CDP unit test pins both halves: a background-tab dialog is
answered on its own session, and a missing session falls back to the
active tab.